This PR makes several suggestions, and should not be considered as is for a merge. A choice on the implementations must be made.

• Implementation of the true visitor pattern (void accept(TopDownVisitor& visitor)) https://refactoring.guru/design-patterns/visitor/cpp/example. It is a new implementation of the visitors, independent from the old visitors.
• Modern and flexible creation of new visitor at the call site using composable callables with the pipe operator. Some old visitors can be replaced by the new mechanism, and the class can be removed.
• Modern and flexible creation of old visitor at the call site. It uses the function makeMechanicalVisitor.
• Some examples of use, and unit tests. In this PR, the file MechanicalOperations uses a mix of old fashion visitors, and new visitors. The file must be reviewed as an example of usage.

Example of the new visitors:

ctx->accept(objectmodel::topDownVisitor
    | [this, &df](core::behavior::BaseForceField* force)
    {
        force->addMBKdx(&mparams, df);
    },
    
    objectmodel::bottomUpVisitor
    | [this, &df, accumulate](core::BaseMapping* mapping)
    {
        if (accumulate)
        {
            mapping->applyJT(&mparams, df, df);
            if( mparams.kFactor() != 0_sreal )
            {
                mapping->applyDJT(&mparams, df, df);
            }
        }
    });

Example of the old visitors:

executeVisitor( makeMechanicalVisitor(&mparams,
    TopDownMassCallable([this, &result](simulation::Node* /*node*/, core::behavior::BaseMass* mass)
    {
        if( mass->m_separateGravity.getValue() )
        {
            mass->addGravityToV(&mparams, result);
        }
        return Visitor::RESULT_CONTINUE;
    })
) );

Pros:

• The pipe operator is consistant with the design of the STL range library.
• No more back-and-forth between the call site and the visitor file. The intention can be read clearly at the call site.
• Dozens of visitor files can be removed
• The new visitor mechanism is much clearer and closer to the visitor design pattern.

Cons:

• A bit of template meta-programming
• Some ugly macros
• The call-stack is a much clearer with the new visitors but still difficult for a novice
• More code at the call site (but it's so much clearer so it's not a con😄 )

TODO with the new visitors:

• Fix ambiguity between BaseForceField and BaseInteractionForceField
• More tests. In particular, with diamond scene graph or multiple parents
• Consistency with BaseMechanicalVisitor and old visitors
• Support detection of mapped states
• constexprify the visitors

The question is: which implementation of the visitors do we keep?

Future work: Implement this kind of "visitor" for the mapping graph

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

Reviewers will merge this pull-request only if

• it builds with SUCCESS for all platforms on the CI.
• it does not generate new warnings.
• it does not generate new unit test failures.
• it does not generate new scene test failures.
• it does not break API compatibility.
• it is more than 1 week old (or has fast-merge label).